1. Field of the Invention
This invention pertains in general to security information/event management (SIM or SIEM) and in particular to tracking state data (e.g., about a network, a device, or another real-world phenomenon) so that the state data can be used in conjunction with security information/events.
2. Description of the Related Art
The field of security information/event management (SIM or SIEM) is generally concerned with 1) collecting data from networks and networked devices that reflects network activity and/or operation of the devices and 2) analyzing the data to enhance security. For example, the data can be analyzed to identify an attack on the network or a networked device and determine which user or machine is responsible. If the attack is ongoing, a countermeasure can be performed to thwart the attack or mitigate the damage caused by the attack. The data that is collected usually originates in a message (such as an event, alert, or alarm) or an entry in a log file, which is generated by a networked device. Exemplary networked devices include firewalls, intrusion detection systems, and servers. The message or entry usually includes a timestamp that reflects when the network activity occurred.
While it is possible to identify and investigate an attack using only the collected data, it is often helpful to have additional information such as the state of the network. A network's state includes, for example, the various devices in the network and how the devices are connected (e.g., the network's topology). Each device also has a state. This state includes various attributes such as, for example, a hardware attribute (e.g., a Media Access Control (MAC) address of the device), a logical attribute (e.g., an Internet Protocol (IP) address assigned to the device), an ownership attribute (e.g., a person or entity who owns the device), a geographical attribute (e.g., a physical location of the device), a software attribute (e.g., an operating system installed on the device), a login attribute (e.g., a user who is currently logged in to the device), a process attribute (e.g., a process that is currently executing on the device), and a network attribute (e.g., an active network connection of the device).
Consider a message that has been identified as being part of an attack. Information in the message might indicate the source device of the attack (e.g., by the device's IP address). This IP address can then be used to identify other messages that are part of the same attack. But it would also be helpful to know to which device the IP address is assigned (e.g., as indicated by the device's MAC address or hostname). If the device/IP address pair is known, then any mention of the IP address can be traced back to the device. Also, if the users logged in to that device are known, then the device can be traced back to the users. If the users' roles are known, then the users can be traced back to their roles, and the roles can be considered in conjunction with the messages that were received and the actions that the messages describe.
Unfortunately, it is not easy to determine the state of the network at any given time. This is because the state is not constant—it changes over time. In particular, each device's state changes over time. For example, the IP address assigned to a device can change over time due to different Dynamic Host Configuration Protocol (DHCP) leases, different Virtual Private Networks (VPNs) being used, or Network Address Translation (NAT). As another example, the users logged in to a device can change over time as various people log in and log out. Thus, it is helpful to know not only the current state of the network but also the past state(s) of the network. Since the attributes of a particular device can change, knowing the correct attributes at any given point in time is helpful in order to correlate events involving the same machine or user.
Consider a user on a first machine trying to log in to a second machine. If the user tries to log in ten times within five minutes and fails each time, then this occurrence should be flagged for review because it might signify an attack. Assume that each failed login generates a message that includes the IP address of the first machine. If the first machine had the same IP address for all ten failed logins, then an attack would be identified. On the other hand, if the first machine changed IP addresses during the attack, then some messages would indicate a first IP address and other messages would indicate a second IP address. Since neither IP address was used for all ten failed logins, nothing would be flagged for review. This is called a false negative.
In this situation, it would be helpful to know the state of the network at the time of the possible attack. For example, at the time of each failed login message, it would be helpful to know to which device (e.g., based on MAC address or hostname) the IP address was assigned. If this were known, then even though the failed logins came from different IP addresses, the IP addresses could be traced back to the same device and an attack could be identified. This is made possible by the fact that MAC addresses and hostnames change less frequently than IP addresses. In other words, IP addresses are more transient than MAC addresses and hostnames.
Note that changing IP addresses can also cause false alarms. Along the lines of the example above, consider four failed logins from one source device and six failed logins from another source device, each occurring within a five-minute time span and directed at the same machine. Although the source devices are different, and they never had the same IP address simultaneously, each device had the same IP address at the time that device caused a failed login. Since this same IP address was present in all ten failed login messages, this occurrence would be flagged for review. This is called a false positive.
What is needed is a way to maintain and query changing state data in an efficient manner so that the data can be used in real-time in conjunction with security information/events.